チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

https://m.media-amazon.com/images/I/51JxJVl5YXL.jpg

ISBN : 978-4-8207-2963-1

自身の学びや感想

新たに学んだこと

改めて、取り組んでいかねばと思ったこと

ソフトウェアのオーナーシップを、安定した (長続きする) チームに割り当てる

次に読みたい本

メモ

まえがき

システムが複雑になるにつれ、2 つの設計領域が重要に

システムの設計

はじめに

全体の流れ

PART 2 は、業界で実績のある静的なチームのパターンについて

PART 3 は、組織設計を進化させる方法について

本書は下記の影響を受けている

大規模ソフトウェアシステムの開発と運用の実践的な成功例

Part 1. デリバリーの手段としてのチーム

1 章 組織図の問題

速いペースのデリバリーとイノベーションの適応の両立には、安定したチーム、効果的なチームパターンとインタラクションが必要

組織図やマトリクスに過度に依存して仕事を分割、管理する組織は失敗しやすい

組織図は実際のコミュニケーションを反映していない

組織図に基づく意思決定は組織の一部分のみに最適化されがち

少なくとも IT 業界においては、プロダクトとチームを中心に据えるが最近の潮流

3 つの組織構造

1. 公式な構造 (組織図) : コンプライアンス遵守を円滑にする

2. 非公式な構造 : 個人間の影響力の領域

3. 価値創造構造 : 個人間やチーム間の能力に基づき、実際にどう仕事を終わらせるか

知的労働組織の成功のカギは、非公式な構造と価値創造構造のインタラクションにある

必要なのは単一の構造ではなく、チームの成長やチーム間のインタラクションを考慮に入れた、状況に適応可能なモデル

1. やむを得ない理由があるときに設計する

2. 設計判断のために選択肢を用意する

3. 適切な時期に設計する

4. 整合性が取れていない箇所を探す

5. 将来を見据える

チームの認知負荷を制限する

文化や組織面での変化は場当たり的

2 章 コンウェイの法則が重要な理由

大企業では、モノリシックな共有データベースがビジネス全体を支えている例に遭遇したことがあるはず

当時はそのアーキテクチャに利点はあったが、今もプロジェクト思考やアウトソーシングによるコスト削減、経験不足な若手チームなどのせいで、このアンチパターンが継続

ものごとを分離し、チームの中にとどめておくことが重要

コンウェイの法則より、チーム構造の決定には技術観点が必要

コミュニケーションが多いほどいいわけではない → 特定のチーム間における集中的なコミュニケーション

不要なコミュニケーションはなくす

3 章 チームファースト思考

ソフトウェアの設計、提供、運用のすべての側面を担う

チームが効果的に働けるようになるには時間がかかる (2 週間～ 3 ヵ月以上)

プロジェクトごとにチームを作り、プロジェクトが終わったら解散するというのは賢明ではない

安定したチームがあることで、ソフトウェアのオーナーシップを改善できる

保守の継続性を提供できる

複数のチームに同一のシステムやサブシステムの変更を許すと、変更やそれがもたらす混乱について誰もオーナーシップを発揮しなくなる可能性

オーナーは単一のチームである必要がある

個人のニーズよりもチームのニーズを優先させる

素早く簡単にチームの認知負荷を知るには、チームに対して 「チームは、頼まれた仕事に対して、効果的でタイムリーな対応ができていると思うか？」 と尋ねてみると良い

Part 2. フローを機能させるチームトポロジー

4 章 静的なチームトポロジー

適切なサポートシステムが必要

それがないとインフラストラクチャやネットワーク、QA などの職能型チームに強く依存するようになってしまう

効果的なチーム構造に影響を与える要素

技術的成熟度と文化的成熟度

組織のサイズやソフトウェアの規模、エンジニアリングの成熟度

フローに最適化したチームにするには、チーム間の依存関係と待ち時間の検出と追跡が不可欠

依存関係には、知識、タスク、リソースの 3 つの異なるカテゴリがある

5 章 4 つの基本的なチームタイプ

「運用チーム」 を作るのではなく、稼働中のソフトウェアをサポート、運用するストリームアラインドチームと、そのチームのための下位の基盤を提供するプラットフォームチーム、という組み合わせ

安全で速い変更フローに最適化

インシデント発生時

ストリームエリア内で解決できるなら、エリア内での単独での解決

6 章 チームファーストな境界を決める

密結合のアーキテクチャ → 「責任が明確で自律的なチーム」 の妨げ

Part 3. イノベーションと高速なデリバリーのためにチームインタラクションを進化させる

7 章 チームインタラクションモード

8 章 組織的センシングでチーム構造を進化させる

環境に合わせて組織が変化する必要 → 組織の設計だけでなく、組織の設計ルール自体も設計すべき

いつチーム構造を進化させるべきか？

1. チームが大きくなりすぎている

チームが大きくなると、チームの中で専門化が引き起こされる

専門化は局所最適化 (「この要求を早くデリバリーする」) のサイクルで強化される

優先すべきことではなく、誰が把握しているかによって計画が左右される → チームの作業フロー全体に悪影響がある可能性 (このレベルの専門化はデリバリーのボトルネック)

チームが担当するシステムの全体を把握しきれなくなる

2. デリバリーのリズムが遅くなり始めている

3. 複数の業務サービスが大量の下位サービスに依存している

素早く行動するために、環境に関するフィードバックセンサーが必要

ひとつの側面 : IT 運用部門のチームを開発部門のチームの高精度な入力センサーとして利用する

9 章 次世代デジタル運用モデル

以下のものが不可欠

健全な組織文化 : 個人やチームレベルで、プロフェッショナルとして成長を促す。 問題について率直に話し、組織として継続的に学ぶ

良いエンジニアリングプラクティス : テストファーストなアプローチ、継続的デリバリーと運用プラクティス、など

プロジェクト指向の納期設定やバッチでの予算割り当てなどをできるだけ避ける

ビジネスビジョンの明確化

チームトポロジーのはじめかた

1. チームから始める

ソフトウェアの一部分にオーナーシップを持つには？ 不要な認知負荷を減らすには？ 他チームのソフトウェアや情報を利用するには？ といったことを考える

2. 安定した変更のストリームを特定する

組織で一番重要な変更が流れるようなパイプとなるストリームをいくつか選択する

組織で一番重要なストリーム上で、安定して素早く変更を流すために必要なサービスは？

4. チームコーチング、メンタリングで能力ギャップを埋める

5. 異なるインタラクションモードを共有、練習し、新しい仕事のやり方の背後にある原則を説明する